According to one observer, if the lifeblood of today's corporations is information, then their arteries are the “inter-application interfaces” that facilitate movement of data around the corporate enterprise. This has more recently become known as an “application network”.
For the typical organization, the application network has grown organically into a collection of ad hoc application integration programs. This menagerie has had a very serious impact on businesses as it increases the time for implementing new applications, prevents senior management from getting a clear picture of the business and, in short, clogs the corporate arteries. In spite of the fact that application integration has become crucial to a competitive corporation's survival, it has nevertheless been acceptable in the prior art to handcraft or “hack” custom code for such purposes at enormous long-term cost to the corporation. Long-term application integration decisions have, likewise, been made at the lowest possible levels based solely on individual project criteria. Because of the decidedly difficult nature of these problems, an effective enterprise application integration (EAI) solution has yet to be found.
The advent of the Internet, client/server computing, corporate mergers and acquisitions, globalization and business process re-engineering, have together forced corporate information technology (IT) departments to continually seek out new, and often manual, ways to make different systems talk to each other—regardless of how old some of those systems may be. In the ensuing chaos, inadequate communications systems have had a debilitating effect on IT's abilities to move as fast as the business needs it to.
On the other hand, typical ERP systems are essentially large, integrated packaged applications that support core business functions, such as payroll, manufacturing, general ledger, and human resources. Implementing an ERP system, however, can be an overwhelming process for a number of reasons.
First and foremost, the corporation is buying a product and not building a solution. This means that business units within the corporation must adapt to the product and how it works, not the other way around. Furthermore, today's ERP systems cannot replace all of a corporation's custom solutions. They must, therefore, communicate effectively with other legacy systems in place. Finally, it is not atypical for a corporation to employ more than one and completely different ERP system because a single vendor cannot usually meet every organizational need.
As a result, the options for getting data into and out of an ERP system preclude known approaches used for data warehousing. Each ERP system has a proprietary data model that is constantly being enhanced by its vendor. Writing extract or load routines that manipulate such models is not only complicated, but is also discouraged by the vendor since data validation and business rules inherent in the enterprise application are likely to be bypassed. Instead, ERPs require interaction at the business object level, which deals with specific business entities such as general ledgers, budgets or accounts payable.
FIG. 1 illustrates a block diagram of a prior art integration system 100 having two different business systems. Local business system 105 represents an ERP business environment, such as those described above, for example a system using the JAVA® environment or SAP® environment. JAVA® is a registered trademark of Sun Microsystems, Inc. SAP® is a registered trademark of SAP Aktiengesellschaft. External business system 125 is an ERP business environment as well, however external system 125 is of a different environment than local system 105; for example a SIEBEL® Business system or Integration Object environment. SIEBEL® is a registered trademark of Siebel Systems, Inc. A problem arises when a user of local system 105 wishes to access external systems 125 within the environment of local system 105. Prior art system 100 solves this problem by having human developer 145 spend hundreds of hours to develop integration code 155. Integration code 155 allows local system 105 to invoke external systems 125 from the local environment. Hand coding by human developer 145 is very expensive, and inefficient because, it may only be used for external system 125. If a second external business system needs to be accessed, human developer 145 must generate new integration code 155. Often, the integration code does not provide a user a coherent interface, with an appearance of being native to local system 105.
In today's rapidly changing environment, the concerted efforts of thousands of developers worldwide are focused on developing a system that satisfies the need for disparate applications to communicate with each other, without the necessity of embedding multiple, customized application-specific translation schemes. This as yet unfulfilled need is grounded in the imperative of the global economy.